refactor(web): let hosts handle request logging - #844

## Why?

Much of the structure around the new SubmitQueue UI is reusable for a
Stovepipe UI as well. This PR pulls out common components into shared
packages that can be used across both services to minimize duplication.

## What?

- Move shared React navigation, polling, timestamp formatting,
path-segment helpers, and styles into `web/platform`
(`@submitqueue/web-platform`).
- Move common Basic auth, Node gRPC transport, Next.js navigation, and
readiness checks into `web/service/shared`
(`@submitqueue/web-service-shared`). Service-specific configuration
stays in the host.
- Update SubmitQueue to import the shared implementations directly,
preserving its public exports and existing behavior.
- Share the Bazel library build, packaging, and lint setup, and update
workspace and package-consumer checks.

## Test Plan

Shared-package checks and the existing SubmitQueue browser suite passed;
the latest rebased stack passed all 32 targets with `./tool/bazel test
//web:check //web/test/e2e/submitqueue:web_test
//web/test/e2e/stovepipe:web_test --test_output=errors`. To validate
this PR independently:

```sh
./tool/bazel test //web:check //web/test/e2e:web_test --test_output=errors
```

Repository formatting, lint, module tidy, and Gazelle checks also
passed.

## Revert Plan

Revert dependent PRs uber#844, uber#838, and uber#837 first if merged, then revert
this PR to restore the original SubmitQueue package layout.

## Stack

1. uber#842 — shared-package refactoring 
2. uber#837 — Stovepipe frontend 
3. uber#838 — browser coverage and E2E organization 
4. uber#844 — host logging integration

## Why?

Stovepipe exposes request lists, status summaries, and history through
RPCs, but has no browser view for inspecting them. Add a basic UI
mirroring the same structure as the SubmitQueue UI: a core component
that can be deployed internally via FusionJS that includes the pages /
contents, and a NextJS wrapper for external use.



https://github.com/user-attachments/assets/0bdf1fd9-36ea-4bea-b540-826d8047e6a2



## What?

- Add `web/stovepipe`, a React library with a request list for each
configured queue and a request page showing the backend status summary
followed by request history.
- Load the summary and events together through `GetRequestHistoryByID`.
Request IDs link to `/<queue>/request/<id>`; change URIs remain
displayed as text. Display the backend summary directly, including
state, change and baseline URIs, timestamps, and outcome reason.
- Provide manual refresh and optional polling, retaining successful
sections when a refresh fails on the same page.
- Add a thin Next.js host under `web/service/stovepipe` for
authentication, configuration, server-side RPC transport, and logging,
plus TypeScript bindings for the existing API and Bazel build/image
targets.
- Add the local Compose overlay and `make local-stovepipe-web-start`,
along with library, component, host, and package tests.

## Test Plan

Latest validation passed all 32 targets with `./tool/bazel test
//web:check //web/test/e2e/submitqueue:web_test
//web/test/e2e/stovepipe:web_test --test_output=errors`, including
real-backend coverage of request-ID navigation, status summaries,
history, and refresh.

Frontend and package checks passed as part of the validation above,
which also built the Stovepipe image. On this PR:

```sh
./tool/bazel test //web:check --test_output=errors
./tool/bazel build //web/service/stovepipe:image
```

For manual review, run `make local-stovepipe-web-start`, open the
printed URL, and sign in with username `test` and password `test` (or
the configured `STOVEPIPE_WEB_TOKEN`).

## Stack

1. uber#842 — shared-package refactoring
2. uber#837 — Stovepipe frontend 
3. uber#838 — browser coverage and E2E organization
4. uber#844 — host logging integration

This PR's diff contains the Stovepipe additions; review the preparatory
refactoring in uber#842. Merge in this order.

## Why?

The new Stovepipe UI needs browser coverage against a real backend, in
addition to its unit and component tests. Align both services' browser
suites under `web/test/e2e/<domain>` so they follow the repository
layout and reuse stack setup helpers.

## What?

- Move the existing SubmitQueue browser suite into
`web/test/e2e/submitqueue`, preserving its browser spec and Compose
overlay.
- Add `web/test/e2e/stovepipe` with real ingestion and seeded pagination
data. Cover queue navigation and cursors, request-ID links and reloads,
backend status summaries above history, refresh, empty queues, and
accessibility. A summary with a newer state than the history verifies
that the UI does not reconstruct status from events.
- Share image loading, schema application, and port lookup helpers. Both
browser runners use the Bazel-pinned Compose executable from uber#830.
- Update Bazel targets and visibility, workspace entries, runner
commands, and test documentation for the new layout. Tests emit queue
and request-page screenshots as Bazel test outputs.

## Test Plan

Latest validation passed all 32 targets, including both services'
real-stack browser suites:

```sh
./tool/bazel test //web:check //web/test/e2e/submitqueue:web_test //web/test/e2e/stovepipe:web_test --test_output=errors
```

Repository formatting, lint, module tidy, and Gazelle checks also
passed. Browser tests require a running Docker daemon; Bazel supplies
Compose and the browser.

## Stack

1. uber#842 — shared-package refactoring 
2. uber#837 — Stovepipe frontend
3. uber#838 — browser coverage and E2E organization
4. uber#844 — host logging integration